home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000594_connolly@pixel.convex.com _Thu Jan 21 23:26:07 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  7KB
  1. Return-Path: <connolly@pixel.convex.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA22226; Thu, 21 Jan 93 23:26:07 MET
  4. Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA14802; Thu, 21 Jan 1993 23:41:33 +0100
  6. Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
  7.     id AA03107; Thu, 21 Jan 93 16:41:43 -0600
  8. Received: from localhost by pixel.convex.com (5.64/1.28)
  9.     id AA24439; Thu, 21 Jan 93 16:40:55 -0600
  10. Message-Id: <9301212240.AA24439@pixel.convex.com>
  11. To: www-talk@nxoc01.cern.ch
  12. Subject: thoughts on the future of HTML [long]
  13. Mime-Version: 1.0
  14. Content-Type: multipart/mixed; boundary="cut-here"
  15. Date: Thu, 21 Jan 93 16:40:54 CST
  16. From: Dan Connolly <connolly@pixel.convex.com>
  17.  
  18. --cut-here
  19.  
  20. HTML was designed to be simple. Folks are supposed to be
  21. able to whack out HTML with a text editor -- no rocket
  22. science required.
  23.  
  24. Also, you ought to be able to use MS/Word or the equivalent
  25. to write your documents or to view HTML documents.
  26.  
  27. But it's also designed to be processed by machine -- lots
  28. of machines all over the planet.
  29.  
  30. Enter SGML.
  31.  
  32. It seemed like the natural choice, so Tim implemented an
  33. informal SGML parser in his WWW clients.
  34.  
  35. Nobody really knew the ins and outs of SGML, so information
  36. providers who wanted to produce HTML automatically just
  37. checked to be sure the public www client grokked.
  38.  
  39. Then other folks tried to write HTML parsers. We discovered
  40. that there were a lot of issues that were not covered by
  41. any spec other than the WWW source code.
  42.  
  43. Then I tried to use the sgmls parser to develop an HTML
  44. to FrameMaker tool. I discovered that the WWW source code
  45. conflicted with the SGML standard. Uh oh!
  46.  
  47. By now I think we all agree that we should actually use SGML
  48. to specify the syntax and structure of HTML.
  49.  
  50. But I wonder: on whom rests the responsibility for validating
  51. HTML documents? This is really an HTTP issue: is it part
  52. of the protocol that the data stream is _valid_ HTML? Or
  53. is it the client's responsibility to deal with errors?
  54.  
  55. I suggest that it should be the responsibility of the _server_
  56. to produce valid HTML. Of course the client should be robust
  57. in the face of errors. But I suggest that when a client and
  58. a server differ on their interpretation of a document, the
  59. client is at fault if the document is valid, and the server
  60. is at fault if the document is not.
  61.  
  62. It's too late to introduce this scenario into HTTP v0.9. But
  63. future servers should have the burden of producing valid documents.
  64. This will add complexity to the server code: it can no longer
  65. just grab the contents of any old .html file and ship it
  66. out the port. But it could, for example, fix the markup errors
  67. on the fly and write error messages to a log file.
  68.  
  69. If a server knows the structure of the document it sends,
  70. it should be able to send the document using SGML, ASN/1,
  71. MIME, or whatever transport mechanism we chose. This is the
  72. real value of standardizing on SGML: the syntax is one
  73. thing, but we don't even have to use it! We have a DTD
  74. that tells, in a more abstract way, what the content of
  75. the document is.
  76.  
  77. With that in mind, I suggest we make HTML2 more prescriptive
  78. than HTML. It should match the way documents are structured
  79. and processed more than the way they are typed in a text editor.
  80.  
  81. For example, the following document is legal, but it's a pain
  82. to process:
  83.  
  84. --cut-here
  85. Content-Type: text/x-html
  86.  
  87. <html>
  88. Here's the first paragraph. It's at the out structural level.<P>
  89.  
  90. The is the <em>Second</em> paragraph.
  91. <body>
  92. Here's another paragraph.
  93. <H1>Another one</h1>
  94. The last paragraph.
  95. </body>
  96. </html>
  97.  
  98. --cut-here
  99.  
  100. Imagine you want to parse that document and answer queries
  101. like: "show me the second paragraph of the document."
  102.  
  103. HTML isn't supposed to be too sophisticated, but it _is_
  104. supposed to model typical word-processor documents fairly
  105. well. A paragraph is a pretty fundamental chunk of information.
  106. The definition of a paragraph in HTML is much more complex
  107. than it need be.
  108.  
  109. Consider the following representation of essentially
  110. the same document:
  111.  
  112. --cut-here
  113. Content-Type: text/x-html
  114.  
  115. <html>
  116.  <body>
  117.   <A>Here's the first paragraph.</A>
  118.   <a>The is the <em>Second</em> paragraph.</a>
  119.   <a>Here's another paragraph.</a>
  120.   <H1>Another one</h1>
  121.   <a>The last paragraph.</a>
  122.  </body>
  123. </html>
  124.  
  125. --cut-here
  126.  
  127. The the elements that make up the content of the BODY are
  128. all paragraphs. Wouldn't it be a lot easier to write
  129. a formatter for the latter type of document?
  130.  
  131. The original HTML design was motivated by conventional use
  132. of SGML, with shortrefs and other markup minimization features
  133. to aid keyboarding of documents.
  134.  
  135. But Tim (wisely) didn't want to put those features in his
  136. parser, so we ended up with a compromise: it's fairly
  137. easy to keyboard, but it has virtually no structure.
  138.  
  139. so...
  140.  
  141. I suggest that future versions of HTML should have more structure.
  142.  
  143. How much structure? Enough. Enough to model whatever kinds of
  144. document make a WWW node. About as much as a TeXinfo node, which
  145. is pretty similar to a FrameMaker TextFlow, or a MS/Word section.
  146. We should probably also model typical markup conventions of internet
  147. mail and USENET news.
  148.  
  149. Then... the big step: hytime. I _really_ think we should look at
  150. hytime architectural forms to model things like threads, webs,
  151. hierarchies of documents, etc.
  152.  
  153. I think we could use HyTime mechanisms to form an abstraction
  154. that models the structure of unix filesystems, message threads,
  155. and other typical hypertext organizations on the internet.
  156.  
  157. This is how we should model "relative links." The unix ../../foo
  158. syntax is fine as a model. But we should abstract the features from
  159. that syntax, so that we can use the same model on VMS systems without
  160. ad-hockery.
  161.  
  162. That syntax happens to work for most gopher holes too,
  163. but that's cheating: the gopher "path" string is supposed to be opaque.
  164. The URL spec says something about how servers that use hierarchical
  165. databases should use the unix path syntax. [What a load of hooey!
  166. Oh... Ahem... sorry.]
  167.  
  168. And the syntax of most WAIS URLs' has _two_ unix paths in it. What
  169. do you do with that?
  170.  
  171. I really think HyTime links and locs are a good way to model all this.
  172. The connection between HyTime and SGML is incidental. The only reason
  173. to use SGML markup is to _interchange_ information between HyTime
  174. applications (...or to talk about HyTime constructs in email, or any
  175. of the other things that text is convenient for.)
  176.  
  177. Standardizing HTML was one thing: it's only used in the WWW community.
  178. But standardizing the WWW addressing architecture is a much larger
  179. venture. I hope eventually the various IETF groups etc. will realize
  180. that the HyTime community has thought about formal mechanisms to
  181. name and reference information a lot, and the product of their labors,
  182. HyTime, may have some technical merit as well as the weight [and
  183. overhead...] of an international standard.
  184.  
  185. Dan
  186.  
  187. p.s. I thought I subscribed to the cni-arch mailing list where URL
  188. stuff was supposed to happen. I don't remember getting anything from
  189. that list for a long time. Is there any URL discussion going on?
  190.  
  191. --cut-here--